Hello, I'm having trouble automating a script I wrote. Please see attachment not sure were I'm going wrong. My actual LinkByKeyV4_8 - timed.dxl script may need to be changed in order to automate the GUI. currently I get a null project being passed? Any help would be appreciated. Thank you. -Jim EHcnck - Sun Feb 02 01:16:26 EST 2014 |
Re: Automating GUI dialog script In batch mode neither current Folder nor current Project nor current Module are set. The script takes care about the current Module, but in your case, since your GUI uses the current project, you need to define that too. I would suggest you do something like "C:\Program Files (x86)\IBM\Rational\DOORS\9.3\bin\doors.exe" -o r -O r -d 65000@1.1.1.1 -f "%TEMP%" -D "string SMODULE = \"%~1\"; #include <export_batch.dxl>" -u Administrator (which means you define only the module name on the command line as a global variable, and then in your export you do: ... current = read(SMODULE, true) // define current Module current = getParentFolder (module SMODULE) // define current Folder current = getParentProject (module SMODULE) // define current Project ... Of course you should introduce sufficient error checking... Regards, Mathias |
Re: Automating GUI dialog script Mathias Mamsch - Sun Feb 02 05:35:04 EST 2014 In batch mode neither current Folder nor current Project nor current Module are set. The script takes care about the current Module, but in your case, since your GUI uses the current project, you need to define that too. I would suggest you do something like "C:\Program Files (x86)\IBM\Rational\DOORS\9.3\bin\doors.exe" -o r -O r -d 65000@1.1.1.1 -f "%TEMP%" -D "string SMODULE = \"%~1\"; #include <export_batch.dxl>" -u Administrator (which means you define only the module name on the command line as a global variable, and then in your export you do: ... current = read(SMODULE, true) // define current Module current = getParentFolder (module SMODULE) // define current Folder current = getParentProject (module SMODULE) // define current Project ... Of course you should introduce sufficient error checking... Regards, Mathias Hello, I modified my script to define the current project but now when I run it I get the following error, any ideas? It seems not to be filling in the DBE for the source ATTRs (current module)
warningBox: Key {'IIIIP - '} !Found Attachments LinkByKeyV4_8 - timed.dxl |
Re: Automating GUI dialog script EHcnck - Sun Feb 02 10:24:31 EST 2014 Hello, I modified my script to define the current project but now when I run it I get the following error, any ideas? It seems not to be filling in the DBE for the source ATTRs (current module)
warningBox: Key {'IIIIP - '} !Found
( Sorry about my question but ... what is the purpose of all those DB / DBE in a batch script ?? |
Re: Automating GUI dialog script pommCannelle - Mon Feb 03 11:41:53 EST 2014
( Sorry about my question but ... what is the purpose of all those DB / DBE in a batch script ?? trying to avoid rewriting an existing script. |
Re: Automating GUI dialog script pommCannelle - Mon Feb 03 11:41:53 EST 2014
( Sorry about my question but ... what is the purpose of all those DB / DBE in a batch script ?? @pommCanelle: This is not really about batch scripts, more an "interactive batch" where you start DOORS in interactive mode but make it invoke an interactive script (like Word Export) and then end itself from the commandline. Regarding the Warning Messages: You should be able to figure out their meaning by debugging your source code. Without digging in and trying to understand the code, I see that these lines
if (find(LookUpLM, strKey, LM) && find(LookUpFM, strKey, FM)) {
// ...
} else {
warningBox("Key {'"strKey"'} !Found")
}
Trigger the warning messages. So this has something to do with the input you provide to the script. Looking at the crash message you did not provide the updated export_batch.dxl script where the error occurs, but my guess is that Line 41 is "if (!null theDiag) destroy theDiag" (a destroy happened already in your script, in which case you need to either remove that line or hook destroy to do nothing and here instead call destroy_old(). Maybe that helps, regards, Mathias |
Re: Automating GUI dialog script Mathias Mamsch - Mon Feb 03 17:53:24 EST 2014 @pommCanelle: This is not really about batch scripts, more an "interactive batch" where you start DOORS in interactive mode but make it invoke an interactive script (like Word Export) and then end itself from the commandline. Regarding the Warning Messages: You should be able to figure out their meaning by debugging your source code. Without digging in and trying to understand the code, I see that these lines
if (find(LookUpLM, strKey, LM) && find(LookUpFM, strKey, FM)) {
// ...
} else {
warningBox("Key {'"strKey"'} !Found")
}
Trigger the warning messages. So this has something to do with the input you provide to the script. Looking at the crash message you did not provide the updated export_batch.dxl script where the error occurs, but my guess is that Line 41 is "if (!null theDiag) destroy theDiag" (a destroy happened already in your script, in which case you need to either remove that line or hook destroy to do nothing and here instead call destroy_old(). Maybe that helps, regards, Mathias I appreciate the help. I was able to get it to work by removing the destroys within the script. I would like to do the hook I understand the overriding of the destroy not sure about the "destroy_old()" can you expand on this? Thank you. void destroy (DB x) {} |
Re: Automating GUI dialog script EHcnck - Mon Feb 03 22:52:00 EST 2014 I appreciate the help. I was able to get it to work by removing the destroys within the script. I would like to do the hook I understand the overriding of the destroy not sure about the "destroy_old()" can you expand on this? Thank you. void destroy (DB x) {} Well it is actually very simple, once you get the idea. Imagine you want to automate a GUI script that does this:
// script.dxl
DB diag = create("...")
// ... create elements ...
DBE bt = button (diag, "Go!", action_handler)
block diag
destroy diag
and you want to automate that script. That means, you neither want to block nor destroy the dialog, instead you want to just realize it, fill in the variables and then call the handler. For this you need to disable block and destroy and call realize instead. So you do:
// this one keeps a way of calling the old block, we dont need it here
// void block_old (DB x) { block x }
void block (DB x) { realize x } // this one replaces block by realize
// this one provides a way of calling the old destroy
void destroy_old (DB x) { destroy x }
void destroy (DB x) { /* do nothing */ }
#include <script.dxl>
// here the dialog box will now be realized, but not destroyed ...
set (dbeElement1, value1)
set (dbeElement2, value2)
action_handler(null DBE); // call the action handler
destroy_old diag // Now destroy the dialog with the old function
So the idea is always, to disable all function that will prevent script.dxl running to its end, back to your code. If for example the script prepares a lot of memory and frees it after the dialog ends:
// script.dxl
Skip skImportant = create()
put (sk, key1, value1) // important data
DB diag = create("...")
// ... create elements ...
DBE bt = button (diag, "Go!", action_handler)
block diag
destroy diag
delete skImportant
Then you can run into the problem that skImportant might be necessary for the functioning of action_handler. So in this case you would also need to prevent deletion of the Skip list or find a way to perform your actions before the delete is executed. Hopefully this is clearer now? Regards, Mathias |